Automatic Mobile Device Configuration

ABSTRACT

A remote wireless device registers with a server. Responsively, the server determines the identity of a server-side application associated with a user of the remote wireless device. The server may then generate an application definition file specific to the server-side application and to the remote wireless device. The application definition file may contain definitions for: a user interface format; a format for network messages; and a format for storing data. Using these definitions, the wireless device may receive data generated by the server-side application and formatted in accordance with the definitions. The wireless device may then present a user interface for the server-side application. The application definition file may be an Extensible Markup Language (XML) file. Advantageously, configuration of devices is more efficiently accomplished.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of application Ser. No. 11/457,841,filed Jul. 17, 2006, the contents of which are hereby incorporated byreference.

FIELD OF TECHNOLOGY

The present disclosure relates to software, devices and methods allowingvaried mobile devices to interact with server-side software applicationsand, more particularly, to the automatic configuration of such mobiledevices.

BACKGROUND

Wireless connectivity is a feature of the modern telecommunicationsenvironment. An increasing range of people are using a wide variety ofwireless data networks to access corporate data applications.

However, there are numerous competing mobile devices (also referred toas “mobile communication devices”) that can be used to achieve this.Each device has its own operating system and its own displaycharacteristics. Operating systems are not mutually compatible, nor arethe display characteristics—some are color, some are black and white,some are text-only, some are pictorial.

At the same time, an increasing number of mobile device users are peoplewithout a technical background or high level of educational achievement.Such people are often intimidated by the need to run complexinstallation programs. Furthermore, at present, such installationprograms generally depend on cable connections to a personal computer bythe means of a “cradle” or other such device.

Therefore, a mechanism whereby a mobile client for a server-sideapplication may be enabled for multiple wireless devices with minimalmodification of the application at the server is required. Further, theability to install and upgrade the application onto mobile deviceswirelessly without the need for human intervention or connection to PCs,is desirable.

BRIEF DESCRIPTION OF THE DRAWINGS

In figures that illustrate, by way of example, embodiments of thepresent disclosure:

FIG. 1 schematically illustrates a mobile device, exemplary of anembodiment of the present application, including virtual machinesoftware, further exemplary of an embodiment of the present application;

FIG. 2 further illustrates the organization of an exemplary virtualmachine at the mobile device of FIG. 1;

FIG. 3 illustrates an operating environment for the device of FIG. 1including a middleware server;

FIG. 4 illustrates the structure of an example application definitionfile stored at the middleware server of FIG. 3 used by the device ofFIG. 1;

FIG. 5 schematically illustrates the formation of application definitionfiles at the middleware server of FIG. 3;

FIG. 6 schematically illustrates the middleware server of FIG. 3,exemplary of an embodiment of the present application, including adatabase, further exemplary of an embodiment of the present application;

FIG. 7 is a sequence diagram illustrating the exchange of samplemessages passed between the mobile device, the middleware server and thebackend application server of FIG. 3;

FIG. 8 illustrates steps performed at a mobile device under control ofthe virtual machine of FIG. 2;

FIG. 9 illustrates steps performed at a mobile device under control ofthe virtual machine of FIG. 2;

FIG. 10 illustrates steps performed at a mobile device under control ofthe virtual machine of FIG. 2;

FIG. 11 illustrates the format of messages exchanged in the message flowof FIG. 7;

FIG. 12 illustrates a presentation of a user interface for a sampleapplication at a mobile device;

FIG. 13 illustrates a sample portion of an application definition filedefining the user interface illustrated in FIG. 12;

FIG. 14 illustrates the format of a message formed in accordance withthe sample portion of the application definition file of FIG. 13;

FIG. 15A illustrates a sample portion of an application definition filedefining a local storage at a mobile device;

FIG. 15B schematically illustrates local storage in accordance with FIG.15A;

FIG. 15C illustrates how locally stored data is updated by a samplemessage in accordance with the sample portion of an application filedefinition of FIG. 15A;

FIG. 16 is a sequence diagram illustrating the exchange of messagesbetween the mobile device and the middleware server; and

FIG. 17 illustrates exemplary steps of a method of automaticallyconfiguring a mobile device according to an embodiment of the presentapplication.

DETAILED DESCRIPTION

Data from an application executing at a computing device may bepresented at a remote wireless device. To assist this presentation, theremote wireless device may be provided with a document that describesaspects of the application to a further application executing on theremote wireless device. The document may, for instance, contain:definitions for a user interface format for the application at thewireless device; a format of network messages for exchange of datagenerated by the application; and a format for storing data related tothe application at the wireless device. Using the definitions, thewireless device may receive data from the application and present aninterface for the application. The document may be an Extensible MarkupLanguage (XML) file. Similarly, application specific network messagesprovided to the device may also be formed using XML. In the preferredembodiment, the data from the application is presented at the mobiledevice by virtual machine software based on the format provided by thedocument.

Where a user of a remote wireless device requires interfaces to a numberof applications, the user may register the device with a server. Uponreceiving a registration request, the server may determine the identityof the user and, subsequently, identify applications associated with theuser. The server may then generate a document specific to eachidentified application and transmit each document to the remote wirelessdevice. Advantageously, the server may determine the type of the remotewireless device and generate the document specific to the type of remotewireless device.

In accordance with an aspect of the present disclosure, there isprovided a method of configuring a mobile communication device. Themethod includes receiving a request for registration of a mobilecommunication device, determining an identity of a user associated withthe mobile communication device, determining an identity of anapplication associated with the identity of the user, generating adocument to describe aspects of the application to a further applicationexecuting on the mobile communication device and transmitting thedocument to the mobile communication device. In other aspects of thedisclosure, a computing device is provided to carry out the method and acomputer readable medium is provided to allow a processor to carry outthe method.

Other aspects and features of the present disclosure will becomeapparent to those of ordinary skill in the art, upon review of thefollowing description of specific embodiments of the application inconjunction with the accompanying figures.

FIG. 1 illustrates elements of a mobile device 10, exemplary of anembodiment of the present application, in communication with a wirelessnetwork 22. The mobile device 10 may be any conventional mobile device,modified to function in manners exemplary of the present application. Assuch, elements of the mobile device 10 include a processor 12, a networkinterface 14, a storage memory 16 and a user interface 18 typicallyincluding a keypad and/or touch-screen. The network interface 14 enablesthe device 10 to transmit and receive data over the wireless network 22.The mobile device 10 may be, for example, be a WinCE based device, aPalmOS device, a WAP enabled mobile telephone, or the like. The storagememory 16 of the device 10 stores operating system software 20 providinga mobile operating system such as the PalmOS or WinCE. The operatingsystem software 20 typically includes graphical user interface softwareand network interface software having suitable application programminginterfaces (APIs) for use by other applications executing at the device10.

The storage memory 16 at the device 10 further stores virtual machinesoftware 29, exemplary of an embodiment of the present application. Thevirtual machine software 29, when executed by the mobile device 10,enables the device 10 to present an interface, for a server-sideapplication provided by a middleware server, as described below.Specifically, a virtual machine 24 (see FIG. 2), which exists through anexecution of the virtual machine software 29 on the processor 12,interprets a document that describes aspects of the server-sideapplication to virtual machine executing on the device 10.

The document, which may be called an “application definition file”, maydefine: a user interface 18 controlling application functionality andthe display format (including display flow) at the device 10 for aparticular server-side application; the format of data to be exchangedover the wireless network 22 for the particular server-side application;and the format of data to be stored locally at the device 10 for theparticular server-side application. The virtual machine 24 uses theoperating system software 20 and associated APIs to interact with thedevice 10, in accordance with the received application definition file.In this way, the device 10 may present interfaces for a variety ofserver-side applications, executed at a variety of servers. Moreover,multiple wireless devices may use a common server-side application, aseach wireless device executes a similar virtual machine that interpretsan application definition file to present a user interface and programflow specifically adapted for the device.

As such, and as will become apparent, the exemplary virtual machinesoftware is specifically adapted to work with the particular mobiledevice 10. Thus, if the device 10 is a PalmOS or WinCE device, thevirtual machine 24 that results from executing the exemplary virtualmachine software 29 is, correspondingly, a PalmOS virtual machine or aWinCE virtual machine. As further illustrated in FIG. 1, the virtualmachine 24 is capable of accessing the local storage 26 at the device10.

Other applications, libraries and software may also be present withinthe memory 16 or the local storage 26 and are not specificallyillustrated. For example, the device 10 may store and execute personalinformation management (PIM) software, including calendar and contactmanagement applications. Similarly, the device 10 could store andexecute software allowing the device 10 to perform a number offunctions. Software could, for example, interact with the hardware atthe device 10 to allow the device 10 to act as a multimedia player;allowing the device 10 to print; allowing the device 10 to interact withother incorporated hardware not specifically illustrated, including, butnot limited to, a Bluetooth interface; a Global Positioning Satellite(GPS) Receiver; and the like. The memory 16 may also store softwarecomponents in the form of object classes that may be used to extend thefunctionality of the virtual machine 24. As will become apparent, theseexternal software components in the form of object classes allow thevirtual machine 24 to become extensible. The object classes may, forexample, allow the virtual machine 24 to access additional hardware orsoftware local to the device 10.

As detailed below, an exemplary application definition file may beformed using a markup language, such as the known Extensible MarkupLanguage (XML) or a variant thereof. In accordance with an embodiment ofthe present application, defined XML entities are understood by thevirtual machine 24. Defined XML entities are detailed in Appendix “A”(FIGS. 16A-16JJ) of U.S. Patent Application Publication 2003/0060896 A9.The defined XML entities are interpreted by the virtual machine 24 andmay be used as building blocks to present an interface, at the mobiledevice 10, to server-side applications, as detailed herein.

Specifically, as illustrated in FIG. 2, the virtual machine software 29includes: conventional XML parser software; event handler software;screen generation engine software; and object classes. The virtualmachine software 29, when executed leads to the virtual machine 24,which includes: an XML parser 61; an event handler 65; a screengeneration engine 67; and instances of the object classes 69. The objectclasses correspond to XML entities supported by the virtual machinesoftware 29 and possibly other XML entities contained within anapplication definition file. Supported XML entities are detailed inAppendix “A” of previously referenced US Patent Application Publication2003/0060896 A9. A person of ordinary skill will readily appreciate thatthose XML entities identified in Appendix “A” are exemplary only and maybe extended or shortened as desired.

The XML parser 61 may be formed in accordance with the Document ObjectModel, or DOM, available at www.w3.org/DOM/, the contents of which arehereby incorporated by reference. The XML parser 61 enables the virtualmachine 24 to read an application description file. Using the XML parser61, the virtual machine 24 may form a binary representation of theapplication definition file for storage at the mobile device 10, therebyeliminating the need to parse text each time an application is used. TheXML parser 61 may convert each XML tag contained in the applicationdefinition file, and its associated data, to tokens, for laterprocessing. As will become apparent, this may avoid the need torepeatedly parse the text of an application description file.

The screen generation engine 67 orchestrates the display of initial andsubsequent screens at the mobile device 10 in accordance with anapplication description file 28, as detailed below.

The event handler 65 allows the virtual machine 24 to react to certainexternal events. Example events include user interaction with presentedscreens or display elements, incoming messages received from a wirelessnetwork, or the like.

The object classes define objects that allow the mobile device 10 toprocess each of the supported XML entities. Each of the object classesincludes: attributes, which are used to store parameters defined by theXML file and functions allowing the XML entity to be processed at themobile device, as detailed in Appendix “A” of previously referenced U.S.Patent Application Publication 2003/0060896 A9, for each supported XMLentity. So, as should be apparent, supported XML entities areextensible. The virtual machine software 29 may be expanded to supportXML entities not detailed in Appendix “A”. Corresponding object classescould be added to the virtual machine software 29.

As detailed below, upon invocation of a particular application at themobile device 10, the virtual machine 24 presents an initial screen onthe user interface 18 based on the contents of the applicationdefinition file 28. Screen elements are created by the screen generationengine 67 by creating instances 69 of corresponding object classes fordefined elements. The object class instances 69 are created usingattributes contained in the application definition file 28. Thereafterthe event handler 65 of the virtual machine 24 reacts to events for theapplication. Again, the event handler 65 consults the contents of theapplication definition file 28 for the application in order to properlyreact to events. Events may be reacted to by instantiating associated“action” objects from the object classes.

Similarly, the object classes of the virtual machine software 29 furtherinclude object classes corresponding to data tables and networktransactions defined in the Table Definition and Package Definitionsections of Appendix “A” of previously referenced US Patent ApplicationPublication 2003/0060896 A9. At run time, instances 69 of object classescorresponding to these classes are created and populated with parameterscontained within the application definition file 28, as required.

Using this general description, persons of ordinary skill in the artwill be able to form the virtual machine software 29 for any particulardevice. Typically, the virtual machine software 29 may be formed usingconventional object oriented programming techniques and existing devicelibraries and APIs, as to function as detailed herein. As will beappreciated, the particular format of the screen generation engine 67and the object class instances 69 will vary depending on the type ofvirtual machine software, the device operating system and the APIsavailable at the device. Once formed, a machine executable version ofthe virtual machine software 29 may be loaded and stored at the mobiledevice 10, using conventional techniques. The machine executable versionof the virtual machine software can be embedded in ROM, loaded into RAMover a network or loaded into RAM from a computer readable medium.Although, in the described embodiment the virtual machine software isformed using object oriented structures, persons of ordinary skill willreadily appreciate that other approaches could be used to form suitablevirtual machine software. For example, the object classes forming partof the virtual machine software 29 could be replaced by equivalentfunctions, data structures or subroutines formed using a conventional(i.e., non-object oriented) programming environment. Operation of thevirtual machine 24 while consulting an application definition filecontaining various XML definitions, is further detailed below.

FIG. 3 illustrates the operating environment for the first examplemobile device 10. Further example mobile devices, including a secondexample mobile device 30, a third example mobile device 32 and a fourthexample mobile device 34 are also illustrated in FIG. 3. These furtherexample mobile devices 30, 32 and 34 are similar to the first examplemobile device 10 and also store and execute virtual machine softwareexemplary of an embodiment of the present application.

Virtual machines, like the virtual machine 24 executed at the firstexample mobile device 10, execute on each of the further example mobiledevices 30, 32, 34, and communicate with a middleware server 44 by wayof a first example wireless network 36, a second example wirelessnetwork 38, a first example network gateway 40 and a second examplenetwork gateway 42. The example gateways 40, 42 are generally availableas a service for those people wishing to have data access to wirelessnetworks. An example network gateway is available from BroadbeamCorporation, of Cranbury, N.J., in association with the trademarkSystemsGo!. The wireless networks 36, 38 are further connected to one ormore computer data networks, such as the Internet and/or private datanetworks by way of the example gateways 40, 42. As will be appreciated,the application may work with many types of wireless networks. Themiddleware server 44 is, in turn, in communication with a data networkthat is in communication with the example wireless networks 36, 38. Thecommunication protocol used for such communication may be HTTP overTCP/IP transport. As could be appreciated, other network protocols suchas X.25 or SNA could equally be used for this purpose.

The mobile devices 10, 30, 32, 34 communicate with the middleware server44 in two ways. First, the virtual machine at each device may query themiddleware server 44 for a list of applications of which a user of anassociated mobile device 10, 30, 32, 34 can make use. If a user decidesto use a particular application, the corresponding mobile device 10, 30,32, 34 can download a text description, in the form of an applicationdefinition file, for the particular application from the middlewareserver 44 over its wireless interface. As noted, the text descriptionmay be formatted using XML. Second, the virtual machine at each devicemay send, receive, present and locally store data related to theexecution of applications, or its own internal operations. The format ofexchanged data for each application is defined by an associatedapplication description file. Again, the exchanged data may be formattedusing XML in accordance with the application description file.

The middleware server 44, in turn, stores text application descriptionfiles for those applications that have been enabled to work with thevarious mobile devices 10, 30, 32, 34 in a pre-defined format understoodby the corresponding virtual machines. Software providing the functionsof the middleware server 44 in the exemplary embodiment is written inDelphi and uses an SQL Server database.

As noted, text files defining application definitions and data may beformatted in XML. For example, XML version 1.0, detailed in the XMLversion 1.0 specification second edition, dated Oct. 6, 2000 andavailable at the internet address www.w3.org/TR/2000/REC-xml-2000-1006,the contents of which are hereby incorporated herein by reference, maybe used. However, as will be appreciated by those of ordinary skill inthe art, the functionality of storing XML description files is notdependent on the use of any given programming language or databasesystem.

Each application definition file is formatted according to defined rulesand uses pre-determined XML markup tags, known to both the virtualmachine executed at the mobile device and the complementary serversoftware executed at the middleware server 44. Tags define XML entities,which are used as building blocks to present an interface to anapplication at a mobile device. Knowledge of these rules, and anunderstanding of how each tag and section of text should be interpreted,allows the virtual machine executed at the mobile device to process anXML application definition file and thereafter provide an interface toan application executed at an application server, as described below.The virtual machine effectively acts as an interpreter for a givenapplication definition file.

FIG. 4 illustrates an example format for an XML application definitionfile 28. As illustrated, the example application definition file 28 fora given mobile device and server-side application includes threecomponents: a user interface definition section 48, specific to the userinterface for the mobile device 10, that defines the format of screen orscreens for the application and how the user interacts with the screens;a network transactions definition section 50 that defines the format ofdata to be exchanged with the application; and a local data definitionsection 52 that defines the format of data to be stored locally on themobile device by the application.

Defined XML markup tags correspond to XML entities supported at a mobiledevice and are used to create an application definition file 28. Thedefined tags may broadly be classified into three categories,corresponding to the three sections 48, 50 and 52 of an applicationdefinition file 28.

Example XML tags and their corresponding significance are detailed inAppendix “A” of previously referenced US Patent Application Publication2003/0060896 A9. As noted above, the virtual machine software 29 at themobile device 10 includes object classes corresponding to each of theXML tags. At run time, instances of the classes are created as required.

Broadly, the following example XML tags may be used to define the userinterface:

<SCREEN>—this tag defines a screen such that a SCREEN tag pair containsthe definitions of the screen elements (buttons, radio buttons and thelike) and the events associated with the screen and the screen controlelements;

<BTN>—this tag defines a button and attributes associated with thebutton;

<LIST>—this tag defines a list box;

<CHOICEBOX>—this tag defines a choice item, which allows selection of avalue from predefined list;

<MENU>—the application developer will use this tag to define a menu fora given screen;

<EDITBOX>—this tag defines an edit box;

<TEXT ITEM>—this tag describes a text label that is to be displayed;

<CHECKBOX>—this tag describes a checkbox;

<HELP>—this tag defines a help topic that is used by another element onthe screen;

<IMAGE>—this tag describes an image that appears on those displays thatsupport images;

<ICON>—this tag describes an icon;

<EVENT>—this tag defines an event to be processed by the virtual machine24 (events can be defined against the application as a whole, individualscreens or individual items on a given screen; sample events include:receipt of data over the wireless interface; and an edit of text in anedit box); and

<ACTION>—this tag defines a particular action that might be associatedwith an event handler (sample actions include: navigating to a newwindow; and displaying a message box.).

The second category of example XML tags may be used in the networktransaction section 50 of the application definition file 28. These mayinclude the following example XML tags:

<TABLEUPDATE>—using this tag, the application developer can define anupdate that is performed to a table in the device-based local storage 26(attributes of this tag allow the update to be performed againstmultiple rows in a given table at once); and

<PACKAGEFIELD>—this tag defines a field in an XML package that passesover the wireless interface.

The third category of XML tags are those used to define a logicaldatabase that may be stored in local storage 26 at the mobile device 10.The tags available that may be used in this section are:

<TABLE>—this tag, along with its attributes, defines a table (containedwithin a pair of <TABLE> tags are definitions of the fields contained inthat table; the attributes of a table control such standard relationaldatabase functions as the primary key for the table); and

<FIELD>—this tag defines a field and its attributes (attributes of afield are those found in a standard relational database system, such asthe data type, whether the field relates to a field in a differenttable, the need to index the field and so on).

The virtual machine 24 may, from time to time, need to perform certainadministrative functions on behalf of a user. In order to do this, oneof the object classes is associated with a repertoire of tags tocommunicate needs to the middleware server 44. Such tags differ from theprevious three groupings in that they do not form part of an applicationdefinition file, but are solely used for administrative communicationsbetween the virtual machine 24 and the middleware server 44. XMLpackages using these tags are composed and sent due to user interactionswith configuration screens of the virtual machine 24. The tags used forthis include:

<REG>—this tag allows the application to register and deregister a userfor use with the middleware server 44;

<FINDAPPS>—by using this tag, users can interrogate the middlewareserver 44 for a list of available applications;

<APPREG>—using this tag, a mobile device can register (or deregister)for an application and have the application definition file downloadedautomatically (or remove the application definition file from thedevice-based local storage 26); and

<SETACTIVE>—using this tag, the user is allowed to identify the devicethat the user is currently using as the active device (if the user'spreferred device is malfunctioning, or out of power or coverage, theuser may need a mechanism to tell the middleware server 44 to attemptdelivery to a different device).

FIG. 5 illustrates the organization of application definition files atthe middleware server 44 and how the middleware server 44 may generatean application definition file 28 (FIG. 4) for a given one of theexample mobile devices 10, 30, 32, 34. In the illustration of FIG. 5,only the first example mobile device 10 and the second example mobiledevice 30 are considered. Typically, since network transactions andlocal data are the same across devices, the only portion of theapplication definition file that varies for different devices is theuser interface definition section 48.

As such, the middleware server 44 stores a master definition file 58 fora given server-side application. This master definition file 58contains: an example user interface definition section 48-10 for thefirst example mobile device 10 of FIG. 1; an example user interfacedefinition section 48-30 for the mobile device 30 of FIG. 3; a userinterface definition section 48-N for an Nth mobile device; adescription of the network transactions that are possible in the networktransactions definition section 50; and a definition of the data to bestored locally on the mobile device in the local data definitionsections 52. Preferably, the network transactions definition section 50and the local data definition sections 52 will be the same for allexample mobile devices 10, 30, . . . , N.

For the first example mobile device 10, the middleware server 44composes the application definition file 28 by determining the devicetype and adding the user interface definition section 48-10 for thefirst example mobile device 10 to the definition sections 50, 52 for thenetwork transactions and the device local data. For the second examplemobile device 30, the middleware server 44 composes the applicationdefinition file by adding the user interface definition section 48-30for the second example mobile device 30 to the definition sections 50,52 for the network transactions and the device local data.

The master definition file 58 for a given application is likely to becreated away from the middleware server 44 and loaded onto themiddleware server 44 by administrative staff charged with the operationof the middleware server 44. Master definition files could be createdeither by use of a simple text editor or by a graphical file generationtool. Such a tool might generate part or all of the file, usingknowledge of the XML formatting rules, based on the user's interactionwith screen painters, graphical data definition tools and the like.

FIG. 6 illustrates the organization of middleware server 44 andassociated master definition files. The middleware server 44 may be anyconventional application server modified to function in mannersexemplary of the present application. As such, the middleware server 44includes a processor 60, a network interface 66, a storage memory 64 anda server database 46. The middleware server 44 may, for example, be aWindows NT server, a Sun Solaris server, or the like. Correspondingly,the storage memory 64 of the middleware server 44 stores a serveroperating system 62 such as Windows NT or Solaris.

The network interface hardware 66 enables the middleware server 44 totransmit and receive data over a data network 63. Transmissions are usedto communicate with both the virtual machine 24 of the first examplemobile device 10, via the wireless networks 36, 38 and the wirelessgateways 40, 42, and a backend application server 70, which may beconsidered representative of one or more application servers. Thebackend application server 70 may be considered both the end recipientof data received by the middleware server 44 from the mobile devices andthe generator of data that is to be sent by the middleware server 44 tothe mobile devices.

The storage memory 64 at the middleware server 44 further storesmiddleware server software 68, exemplary of an embodiment of an aspectof the present application. The middleware server software 68, whenexecuted by the processor 60 of the middleware server 44, enables themiddleware server 44 to compose and understand XML packages that aresent by and received by the middleware server 44. These XML packages maybe exchanged between the middleware server 44 and the first examplemobile device 10 or between the middleware server 44 and the backendapplication server 70.

As mentioned above, communication between the backend application server70 and the middleware server 44 may use HTTP running on top of astandard TCP/IP stack. An HTTP connection between a running applicationat the backend application server 70 and the middleware server 44 may beestablished in response to receipt of an XML package from a mobiledevice. The server-side application executed at the backend applicationserver 70 provides output to the middleware server 44 over thisconnection. The server-side application output may be formatted, by theserver-side application, into appropriate XML packages understood by thevirtual machine 24 at the first example mobile device 10.

That is, a given server-side application (or an interface portion of theserver-side application) formats server-side application output into anXML package in a manner consistent with a format defined in theapplication definition file for the given server-side application.Alternatively, an interface component, separate from the server-sideapplication, could easily be formed with an understanding of the formatfor output for the given server-side application. That is, with aknowledge of the format of data provided by and expected by the givenserver-side application at the backend application server 70, aninterface component could be a produced using techniques readilyunderstood by those of ordinary skill. The interface component couldtranslate the output of the given server-side application to an XMLpackage, as expected by the middleware server 44. Similarly, theinterface portion may translate an XML package received, via themiddleware server 44, from the mobile device 10 into a format understoodby the given server-side application.

The particular identity of the mobile device on which the interface tothe server-side application is to be presented may be specified by asuitable identifier, contained in a header prefixed to the server-sideapplication output XML package. This header may be used by themiddleware server 44 to determine the appropriate mobile device to whichto forward the XML package. Alternatively, the identity of theconnection between the backend application server 70 and the middlewareserver 44 could be used to determine, at the middleware server 44, theappropriate mobile device to which to forward the XML package.

FIG. 7 illustrates a flow diagram detailing data flow (application dataor application definition files 28) between the mobile device 10 and themiddleware server 44, in manners exemplary of an embodiment of thepresent application.

For data requested from the middleware server 44, the device 10, undersoftware control by the virtual machine software, transmits requests tothe middleware server 44 (see also FIG. 3), which requests pass over thefirst wireless network 36 to the first network gateway 40. The firstnetwork gateway 40 passes the request to the middleware server 44. Theprocessor 60 of the middleware server 44 responds by executing adatabase query on the server database 46. The response to the query isan indication of the applications that are available to the user and themobile device 10. Data representative of the indication is passed, bythe middleware server 44, to the first network gateway 40. The firstnetwork gateway 40 forwards the data representative of the indication tothe mobile device 10 over the first wireless network 36.

FIG. 7, when considered with FIG. 3, illustrates a sequence ofcommunications, between the virtual machine 24 at the device 10 and themiddleware server 44, that may occur when the user of the mobile device10 wishes interact with a server-side application. Accordingly,initially, the virtual machine 24 interrogates the middleware server 44to determine the applications that are available for the first examplemobile device 10. This interrogation may be initiated by the userinstructing the virtual machine 24 at the first example device 10 tointerrogate the middleware server 44. Responsive to these instructions,the virtual machine 24 composes an XML package requesting the list ofapplications. The wireless interface hardware 14 (see FIG. 1) of themobile device 10 transmits the XML package to the middleware server 44(data flow 72). The XML message may be composed to contain a <FINDAPPS>tag, signifying, to the middleware server 44, a desire for a list ofavailable applications. In response, the middleware server 44 makes aquery to the server database 46. The server database 46, responsive tothis query, returns a list of applications that are available to theuser and to the first example mobile device 10. The list is typicallybased, at least in part, on the type of mobile device making therequest, the identity of the user of the mobile device and theapplications known to the middleware server 44. The middleware server 44converts the list into an XML list package and transmits the XML listpackage, including a list of available applications, to the mobiledevice 10 (data flow 74). Again, a suitable XML tag identifies the XMLlist package as containing a list of available applications.

In response to being presented with the list of available applications,a user at the first example device 10 may choose to register for anavailable server-side application in the list. When the user chooses toregister for an application, the virtual machine 24 at the device 10composes a registration request XML package containing a registrationrequest for the selected application. The wireless interface hardware 14transmits the registration request XML package to the middleware server44 (data flow 76). The registration request XML package may contain a<REG> tag. The name of the application is specified in the registrationrequest XML package. The middleware server 44, in response to receivingthe registration request XML package, queries the server database 46 fora user interface definition associated with the specified applicationand the first example mobile device 10. Thereafter, the middlewareserver 44 creates the application definition file, as detailed withreference to FIG. 5. Then, the middleware server 44 composes an XMLpackage including the composed application definition file and transmitsthe XML package to the mobile device 10 (data flow 78).

The user is then able to use the functionality defined by theapplication definition file to send and receive data.

After receiving the XML package including the application definitionfile, the XML parser 61 of the virtual machine 24 may parse the XML textof the application definition file to form a tokenized version of theapplication definition file. That is, each XML tag of the applicationdefinition file may be converted to a defined token for compact storageand to minimize repeated parsing of the XML text file. The tokenizedversion of the application definition file may then be stored forimmediate or later use by the device 10.

Thereafter, upon invocation of an interface to the particularapplication for which the device 10 has registered, the screengeneration engine 67 of the virtual machine 24 locates the definition ofan initial screen for the particular application. The initial screen maybe identified within the application definition file for the particularapplication as corresponding to a <SCREEN> tag with an associatedattribute of First screen=“yes”.

Exemplary steps performed by the virtual machine 24 in processing theinitial screen (and any screen) are illustrated in FIG. 8. Asillustrated, the screen generation engine 67 generates an instance of anobject class, defining a screen by parsing the section of theapplication definition file corresponding to the <SCREEN> tag in stepS802. Supported screen elements may be buttons, edit boxes, menus, listboxes and choice items, as identified in sections 5.3, 5.4 and 5.5 ofAppendix “A” of previously referenced US Patent Application Publication2003/0060896 A9. Other screen elements, such as images and checkboxes,as detailed in Appendix “A”, may also be supported. However, for clarityof illustration, the processing of the other screen elements by thescreen generation engine 67 is not detailed. Each supported tag underthe SCREEN definition section, in turn, causes creation of instances 69of object classes within the virtual machine 24. Typically, instances ofobject classes corresponding to the tags, used for creation of a screen,result in presentation of data at the mobile device 10. As well, thecreation of such instances may give rise to events (e.g., userinteraction) and actions to be processed at the device 10.

Each element definition causes the virtual machine 24 to use theoperating system of the mobile device 10 to create a correspondingdisplay element of a graphical user interface as more particularlyillustrated in FIG. 9. Specifically, for each element, the associatedXML definition is read in step S806, S816, S826, S836, and S846, and acorresponding instance of a screen object class defined as part of thevirtual machine software is created by the virtual machine 24 in stepsS808, S818, S828, S838 and S848, in accordance with steps S902 andonward illustrated in FIG. 9. Each interface object is instantiated instep S902. Each object takes as attribute values defined by the XML textassociated with the element. A method of the object is further called instep S904 and causes a corresponding device operating system object tobe created. Those attributes defined in the XML text file, and storedwithin the virtual machine object instance, are applied to thecorresponding display object created using the device operating systemin steps S908S-S914. These steps are repeated for all attributes of thevirtual machine object. For any element allowing user interaction,giving rise to an operating system event, the event handler 65 of thevirtual machine 24 is registered to process operating system events, asdetailed below.

Additionally, for each event (as identified by an <EVENT> tag) andaction (as identified by an <ACTION> tag) associated with each XMLelement, the virtual machine 24 instantiates a corresponding eventobject and action object forming part of the virtual machine software.The virtual machine 24 further maintains a list identifying each eventobject and each action object, and an associated identifier of an eventin steps S916 to S928.

Steps S902-5930 are repeated for each element of the screen in stepsS808, S818, S828, S838 and S848 as illustrated in FIG. 8. All elementsbetween the <SCREEN> definition tags are so processed. After the entirescreen has been so created in memory, it is displayed in step S854,using conventional techniques.

As will be appreciated, objects are specific to the type of deviceexecuting the virtual machine software. Functions initiated as a resultof the XML description may require event handling. This event handlingis processed by the event handler 65 of the virtual machine 24 inaccordance with the application definition file 28. Similarly, receiptof data from a mobile network will give rise to events. The eventhandler 65, associated with a particular application presented at thedevice, similarly processes incoming messages for that particularapplication. In response to the events, the virtual machine 24instantiates software objects and calls functions of those objects, asrequired by the definitions contained within the XML definitionscontained within the application definition file 28, giving rise to theevent.

As noted, the virtual machine software 29 includes object classes,allowing the virtual machine 24 to instantiate objects corresponding toan <EVENT> tag. The event object classes include methods specific to themobile device that allow the device to process each of the defined XMLdescriptions contained within the application definition file and alsoallow the device to process program/event flow resulting from theprocessing of each XML description.

Events may be handled by the virtual machine 24 as illustrated in FIG.10. Specifically, as the event handler 65 has been registered with theoperating system for created objects, upon occurrence of an event, stepsS1002 and onward are performed in response to the operating systemdetecting an event.

An identifier of the event is passed to the event handler 65 in stepS1002. In steps S1004-S1008, this identifier is compared to the knownlist of events, created as a result of steps S916-S930. For anidentified event, actions associated with that event are processed instep S1008-S1014. That is, the virtual machine 24 performs the actiondefined in the <ACTION> tag associated with the <EVENT> tagcorresponding to the event giving rise to processing by the eventhandler 65. The <ACTION> may cause creation of a new screen, as definedby a screen tag, a network transmission, a local storage, or the like.

New screens, in turn, are created by invocation of the screen generationengine 67, as detailed in FIGS. 8 and 9. In this manner, the navigationthrough the screens of the application is accomplished according to thedefinition embodied in the application definition file.

Similarly, when the user wishes to communicate with the middlewareserver 44, or store data locally, the event handler 65 creates instances69 of corresponding object classes of the virtual machine software 29and calls methods of the instances to transmit the data, or store thedata locally, using the local device operating system. The format of thedata stored locally is defined by the local data definition section 52;the format of XML packages transmitted or received is defined in thenetwork transaction package definition section 50.

For example, data that is to be sent to the wireless network isassembled into XML packages using methods of an XML builder object.Methods defined in as part of the XML builder object allow creation of afull XML package before passing the completed XML package to a messageserver object. The message server object uses the device's network APIsto transmit the completed XML package across the wireless network.

XML packages received from the data network 63 (FIG. 6) give rise toevents processed by the event handler 65. Processing of the receipt ofXML packages is not specifically illustrated in FIG. 9. However, thereceipt of a XML package triggers a “data” event recognized by thedevice operating system 20 (see FIG. 1). This data event is passed tothe virtual machine 24 and the event handler 65 inspects the receivedXML package. As long as the data received is a valid XML data package ascontained within the application definition file, the virtual machine 24inspects the list of recognized XML entities.

So, for example, a user could trigger the transmission of a loginrequest (data flow 80, FIG. 7) by interacting with an initial loginscreen, defined in the application definition file for the application.The login request (data flow 80) would be passed by the middlewareserver 44 to the backend application server 70. The backend applicationserver 70, according to the logic embedded within its application, wouldreturn a login response (data flow 82), which the middleware server 44would pass to the virtual machine 24. Other applications, running on thesame or other application servers might involve different interactions,the nature of such interactions being solely dependent on thefunctionality and logic embedded within the backend application server70 and remaining independent of the middleware server 44.

FIG. 11 illustrates example XML messages passed as part of the messageflows illustrated in FIG. 7. For each message, the header portion, i.e.,the portion enveloped by the <HEAD></HEAD> tag pair, is considered tocontain a timestamp and an identifier of the sending device.

A first example message 72 is representative of a message sent by themobile device 10 to request the list of applications that the middlewareserver 44 has available to that user on that device. The first examplemessage 72 specifies a type for the mobile device 10 using textcontained by the <PLATFORM></PLATFORM> tag pair. A second examplemessage 74 is representative of a message sent, to the mobile device 10by the middleware server 44, in response to the first example message72. The second example message 74 contains a set of <APP></APP> tagpairs, each tag pair enveloping an identity of a single application thatis available to the user at the device 10. A third example message 76 isrepresentative of a message sent from the mobile device 10 to themiddleware server 44 to request registration for a single server-sideapplication. The tags specify information about the user and the mobiledevice 10. A fourth example message 78 is representative of a messagesent, to the mobile device 10 by the middleware server 44, in responseto the third example (registration request) message 76. The<VALUE></VALUE> tag pair envelope a code indicating success or failure.In the fourth example message 78 shown, a success is indicated by“CONFIRM” and is followed by an interface description for theapplication, enveloped by the <INTERFACE></INTERFACE> tag pair. Thisinterface description may then be stored locally within the storagememory 16 of the mobile device 10.

As noted, when a user starts an interface to an application, anapplication definition file for which has been downloaded in the mannerdescribed above, the virtual machine 24 reads the interface descriptionsection of the application definition file. The virtual machine 24identifies the screen that should be displayed on startup and displaysthe elements of the screen as detailed in relation to FIGS. 9 and 10.The user may then use the functionality defined by the applicationdefinition file to send XML packages to, and receive XML packages from,the associated backend application server via the middleware server 44.

For the purposes of illustration, FIGS. 12 and 13 illustrate thepresentation of a user interface for a sample screen on a Windows CEPortable Digital Assistant. As illustrated in FIG. 13, a first XMLportion 92 of the application definition file 28 is an interfacedescription for a screen with the name “NewMsg”. This interfacedescription may be contained within the user interface definitionsection 48 of the application definition file 28 associated with theserver-side application. The screen is defined to have a single buttonidentified by a <BTN> tag, which is identified as item D in FIG. 13,with attributes NAME=“OK”, CAPTION=“Send”, INDEX=“0”, X=“0”, Y=“15”,HT=“18” and WT=“50”. This button gives rise to a single event(identified by the <EVENTS> tag) that has two associated actions: onedefined by the <ACTION> tag with attribute TYPE=“SAVE”; and one definedby the <ACTION> tag with attribute TYPE=“ARML”. The latter actionresults in the generation of an XML package (defined by the <PKG> tagwith attribute TYPE=“ME”), which has a data format as defined envelopedby the <PKG></PKG> tag pair. The package is defined to begin with a<MAIL> TAG with attributes MSGID, FROM and SUBJECT. Additionally, theinterface description for the screen includes definitions for three editboxes, as enveloped by the <EDITBOXES></EDITBOXES> tag pair. Thedefinitions for the three edit boxes are identified in FIG. 13 as linesof XML code labeled A, B and C.

Upon invocation of the interface to the server-side application at themobile device 10, the screen generation engine 67 of the virtual machine24 processes the interface definition for the screen, as detailed withreference to FIGS. 8 and 9. That is, for XML tag D, the screengeneration engine 67 creates a button object in accordance with stepsS804-S812. Similarly for XML tag pairs A, B and C within the applicationdefinition file 28, the virtual machine 24 instantiates edit box objects(i.e., steps S834-S842, see FIGS. 8 and 9). The data contained withinthe object reflects the attributes of the relevant button and edit boxtags, contained in the application definition file 28 associated withthe server-side application.

The resulting screen presented by the user interface 18 of the mobiledevice 10 is illustrated in FIG. 12. The user interface 18 depicts ascreen called “NewMsg”, which uses interface items that provide a userwith an ability to compose and send data. The screen illustrated in FIG.12 has an edit box named “To” 84 corresponding to XML tag pair A in FIG.13, an edit box named “Subject” 86 corresponding to XML tag pair B inFIG. 13 and an edit box named “Body” 88 corresponding to XML tag pair Cin FIG. 13. The screen illustrated in FIG. 12 also incorporates a buttonnamed “OK” 90 corresponding to XML tag D in FIG. 13.

Call-backs associated with the OK button 90 cause graphical userinterface application software, as part of the operating system at themobile device 10, to return control to the event handler 65 of thevirtual machine 24. Thus, as the user interacts with the user interface18, the user may input data within the presented screen using the mobiledevice API. Once data is to be exchanged with the middleware server 44,the user may press the OK button 90 and, by doing so, invoke an event,which is initially handled by the operating system of the mobile device10. However, during the creation of the OK button 90, in stepsS804-S810, any call-back associated with the button was registered to behandled by the event handler 65 of the virtual machine 24. Uponcompletion, the virtual machine 24 receives data corresponding to theuser's interaction with the user interface 18 and packages this datainto an XML package using corresponding objects. The XML package ispopulated according to the rules within the application definition file28.

The event handler 65, in turn, processes the event caused by userinteraction with the OK button 90 in accordance with the <EVENT> tag andcorresponding <ACTION> tag associated with the <BTN> tag, referenced asXML tag D, associated with the OK button 90. The events, and associatedactions, are listed as data items associated with the relevant userinterface item within the application definition file 28. The <ACTION>tag causes the virtual machine 24 to instantiate an object that forms anXML package for transmission to the middleware server 44 in accordancewith the format defined within the <ACTION></ACTION> tag pair. That is,a “template” (defined beginning with the <PKG> tag with attributeTYPE=“ME”) for the XML package to be sent is defined within the<EVENT></EVENT> tag pair for a given user interface item. This templatespecifies the format of the XML package to be sent and may includecertain variable fields. The variable fields in the formatted XMLpackage take on contents that vary according to the values received indata entry fields on the current and previous screens. The definition ofthe template specifies which data entry field should be interrogated topopulate a given variable field within the XML package that is to besent.

According to the template, some of the variable fields of the XMLpackage are filled dynamically from data inserted by the user into editboxes presented on the display of the mobile device 10. The templateincludes placeholders delimited by square brackets, i.e., “[” and “]”.These placeholders reference a data source from which data for fillingthe corresponding section of the template should be obtained. A suitabledata source might be a user interface field on the current screen, auser interface field on a previous screen or a table in a device-basedlogical database. The virtual machine 24, after reading the data sourcename, searches for the field corresponding to the referenced data sourceand replaces the placeholder with data contained within the named field.For example, the SUBJECT attribute of the <MAIL> tag in the first XMLportion 92 references [NewMsg.Subject]. As such, content for the SUBJECTattribute may be read from the edit box (field) named “Subject” on thescreen named “NewMsg”. This process is repeated for each suchplaceholder, until the virtual machine 24, reading through the template,has replaced all placeholders in the template with content to form anXML package.

An exemplary XML package 94, containing data obtained as a result ofinput provided to the fields of the “NewMsg” screen, is illustrated inFIG. 14. The exemplary XML package 94 may have been created responsiveto user interaction with the “NewMsg” screen, which user interaction maybe considered to have been culminated by interaction with the OK button90 (see FIG. 12) corresponding to XML tag D in the first XML portion 92.In this case, the user has entered: the text “steven@nextair.com” intothe edit box named “To” 84; the text “Hello Back” into the edit boxnamed “Subject” 86; and the text “I am responding to your message” intothe edit box named “Body” 88.

The virtual machine 24, using the template, inspects these three editboxes and places the text contained within each edit box in theappropriate position in the template. For example, the placeholder[NewMsg.Subject] is replaced by “Hello Back”. The virtual machine 24creates the exemplary XML package 94 by invoking functionality embeddedwithin an XML builder software object to populate the variable fields ofthe template contained in the first XML portion 92. Once the exemplaryXML package 94 has been assembled in this fashion, a relevant method ofthe message server object is invoked to transmit the exemplary XMLpackage 94 across the network.

When an XML package is received, the event handler 65 of the virtualmachine 24 is notified. In response, the virtual machine 24 the XMLparser 61 to build a list of name value pairs contained within thereceived XML package. Thereafter, methods within an object class forprocessing incoming XML packages are invoked that allow the virtualmachine 24 to inspect the XML package to determine a server-sideapplication to associate with the XML package and select a correspondingapplication definition file. The methods within the object class forprocessing incoming XML packages also allow the virtual machine 24 toinspect the application definition file to identify the fields in thedevice-based logical database and the user interface screens that mayneed to be updated with new data received in the XML package. In thecase wherein the user interface screens are updated, such updating maybe accomplished according to the procedures normal to the particulardevice.

Handling of incoming XML packages is defined in the applicationdefinition file 28. That is, for each of the possible XML packages thatcan be received, the application description file 28 includesdefinitions of device-based logical database tables and screen itemsthat should be updated, as well as which section of the package updateswhich device-based logical database table or screen item. After an XMLpackage has been received, the event handler 65 uses rules based on theapplication description file 28 to identify which device-based logicaldatabase tables or screen items need to be updated.

FIGS. 15A-15C illustrate how the format of the logical database in thelocal storage 26 on the device 10, and the XML packages that update thelogical database, are defined in the application definition file 28. Asecond XML portion 96 of the application definition file 28, illustratedin FIG. 15A, forms part of the local data definition section 52 (seeFIG. 4). The second XML portion 96 defines an example format for aportion of the logical database related to the e-mail applicationinterface described with reference to FIGS. 12 and 13.

Two example tables are defined in the second XML portion 96 of FIG. 15Afor formatting the logical database for the e-mail application. A firstXML item E of the second XML portion 96 corresponds to a first table,labeled “SENTITEMS” in FIG. 15B. A second XML item F of the second XMLportion 96 corresponds to a second table, labeled “RECIPIENTS” in FIG.15B. The first table stores details of sent e-mail messages and has fourfields. The second table stores recipients of sent e-mail messages andhas three fields.

FIGS. 15A and 15B illustrate the use of the local storage 26 to storedata related to XML packages that are sent and received. Specifically,the first table, defined by the first XML item E in FIG. 15A, may storethe e-mail message contained in the exemplary XML package 94, shown inFIG. 14. Accordingly, the application definition file 28 for the e-mailapplication may be required to contain, along with the first XML portion92 and the second XML portion 96, a third XML portion 102, illustratedin FIG. 15C. The third XML portion 102 defines how the data packages,composed according to the template included in the first XML portion 92(see FIG. 13), lead to updates of the tables defined by the second XMLportion 96.

The third XML portion 102 includes a first section 104 and a secondsection 106. The first section 104 defines how fields of a received XMLpackage may be used to update the first table of FIG. 15B. An exampleline 108 defines how the “MSGID” field of the received XML package maybe used to update a field named “LNGMESSAGEID” in the first table ofFIG. 15B. Similarly, the second section 106 defines how the fields ofthe received XML package may be used to update fields of the secondtable of FIG. 15B.

The third XML portion 102 is contained by an<AXDATAPACKET></AXDATAPACKET> tag pair. Attributes of the <AXDATAPACKET>tag provide rules that instruct the virtual machine 24 as to whetherdata contained within an XML package of a given XML package type shouldbe used to update tables in the device-based logical database. Theserules may be applied whenever an XML package of the given XML packagetype is sent or received.

As can be seen from the preceding description and example, such anapproach has significant advantages over traditional methods ofdeploying applications onto mobile devices. First, the definition of anapplication's functionality is separated from the details associatedwith implementing such functionality, thereby allowing the implementersof a mobile application to concentrate on the functionality and ignoreimplementation details. Second, application definition files can bedownloaded wirelessly, wherever the device happens to be at the time atwhich the functionality is required. This greatly improves theusefulness of the mobile device, by removing reliance on returning thedevice to a cradle and running a complex installation program. Third,the use of application definition files allows flexible definitions fornumerous applications. Server-side applications may be easily ported toa number of device types.

Notably, mobile communication devices of the current generation may actnot only as a mobile telephone, but also may execute an e-mail clientapplication, a personal information manager (PIM) application, a digitalphoto organizer application, etc. There are often many, widely variedoptions that may be configured. While some of the options are related topersonalization of the mobile device, proper configuration of otheroptions may be essential to a proper interaction between the mobiledevice and an enterprise with which a user of the mobile device isassociated.

When a new mobile device is issued to an individual associated with theenterprise, an information technology (IT) specialist may be given thetask of configuring the new mobile device for use with the enterprise.To this end, the IT specialist may be required to navigate multiplescreens on the new mobile device to set communications or other devicesettings.

In view of the above disclosure, the IT specialist may be required toseparately request an application definition file for each server-sideapplication of potentially many server-side applications with which thenew mobile device is expected to interact.

In another scenario, an employee with a previously personalized andconfigured mobile device may require that a replacement mobile device besimilarly personalized and configured. The replacement mobile device maybe required due to the loss of a previous mobile device, software orhardware failure of the previous mobile device or merely a hardwareupgrade from the previous mobile device to a newer mobile device.

Such personalization and configuration of mobile devices, thoughbeneficial, may be considered tedious and time consuming.

In overview, the use of application definition files, as disclosedabove, allows for a record to be maintained at the middleware server 44of any application definition files provided to a given user.Furthermore, the given user may be grouped with other users with whichthe given user shares some commonality, be it a common managerialstratum, a common supervisor or a common rate plan.

A mobile device may trigger automatic mobile device configuration byperforming an initial registration process with the middleware server44. Such an initial registration process may, for instance, involve thevirtual machine 24 (see FIG. 2) executed at the first exemplary mobiledevice 10 (see FIG. 1 and FIG. 3) formulating and transmitting aregistration request 1602 (see FIG. 16) to the middleware server 44.

In view of FIG. 17, the middleware server 44 receives (step 1702) theregistration request. In particular, in an exemplary case similar to thereceipt of a request detailed above, the registration request passesfrom the first exemplary mobile device 10 to the first network gateway40 over the first wireless network 36 (see FIG. 3). The first networkgateway 40, which may be part of the data network 63 illustrated in FIG.6, passes the registration request to the middleware server 44. Thenetwork interface hardware 66 of the middleware server 44 receives theregistration request and stores the registration request in the memory64 such that the registration request is available for processing by theprocessor 60.

Processing of the registration request may, for example, involve theprocessor 60 determining the user ID (step 1704) associated with thedevice that formulated the registration request. Such a user ID may bearranged to be part of a registration request that conforms to astandard for such requests. For instance, the user ID may be containedin a User ID field of the registration request or, where theregistration request is formed in XML or a variant thereof, theregistration request may include a User ID element. In either case, themiddleware server 44 may parse the received registration request todetermine the associated user ID.

Once the processor 60 has determined the user ID for a givenregistration request, the processor 60 may, based on the user ID,determine (step 1706) a set of N server-side applications that have beenpreviously associated with the user ID, say, in the server database 46(see FIG. 6). The previous association between user ID and server-sideapplications may be manually established by an administrator of themiddleware server 44 or automatically established through historicalmonitoring of requests made by a mobile device associated with the userID.

The processor 60 may then generate (step 1708) an application definitionfile for the mobile device for each of the server-side applications inthe determined set. Generation of an application definition file (step1708) has been described above in conjunction with the description ofFIG. 4 and FIG. 5 to involve determination of a device type for themobile device requesting the application definition file and theaddition of the type-appropriate user interface definition section 48 tothe network transactions definition section 50 and the local datadefinition sections 52.

Once the first application definition file is generated, the middlewareserver 44 may transmit (step 1710) the first application definition file1604-1 (see FIG. 16) to the mobile device. Once the second applicationdefinition file is generated, the middleware server 44 may transmit(step 1710) the second application definition file 1604-2 (see FIG. 16)to the mobile device. Such generation (step 1708) and transmission (step1710) may continue until the Nth application definition file 1604-N hasbeen generated (step 1708) and transmitted (step 1710) to the mobiledevice.

The administrator of the middleware server 44 may independentlydetermine the set of applications appropriate to the user and save therecord of the set of applications in the database 46 in association withthe user ID of the user. Alternatively, the administrator may establisha single record of the set of applications to associate with users thathave common properties and, consequently, common applicationrequirements. In such a case, the administrator may create a GroupListing record, wherein the user IDs of the members of the group arelisted. The Group Listing record may be associated with an ApplicationListing record, which identifies applications that are to be associatedwith the user IDs listed in the Group Listing record. As such, moreefficient associations are possible.

Beyond the application definition files that are associated withserver-side applications, there may exist application definition filesthat provide various settings for the mobile device.

In a first example, an application definition file may provide themobile device with a particular telephone number that a device is to usefor a dial-up connection to a specific network. Alternatively, anapplication definition file may provide a particular Internet Protocol(IP) address to which the device is to connect as a point of serverconnection. For instance, a user may need to connect to a particularcomputer, at the particular IP address, that is in a designateddemilitarized zone. In computer security terminology, a demilitarizedzone is a network area that sits between an organization's internalnetwork and an external network, usually the Internet. The user may needto connect to the particular computer for business transactions, so,after an initial login, the user may want to bere-configured/re-directed to a different entry point to the corporateLAN.

In another example, an application definition file may provide themobile device with an address for a Virtual Private Network (VPN) serverthat provides secure, authenticated network connections. For instance,the user may be required to be authenticated before being able to accessa Local Area Network (LAN) for access to corporate applications. Theapplication definition file may also provide encryption key settings andan indication of an authentication protocol (HTTP, LDAP, NT, etc.).

The mobile device may regularly establish a connection to a servergateway. Based on a type for the connection being established to theserver gateway, an optimized protocol may be selected. The optimizedprotocol may be, for instance, the known Transport ControlProtocol/Internet Protocol (TCP/IP) or the User Datagram Protocol. Thedecision of which protocol to use may be, for instance, based on whetherthe mobile device is establishing the connection to the server gatewayover a Wide Area Network, over a public wireless network or over aprivate WiFi network. In addition, a separate configuration may berequired for each network, if the device supports roaming between thesedifferent technologies. An application definition file may provide themobile device with a mapping between type of connection and optimizedprotocol. Additionally, the application definition file may provide themobile device with configuration details for each of the protocols.

In a further example, an application definition file may provide themobile device with configuration details for delivery mechanisms. Themost efficient data delivery mechanism may depend on aspects of theserver-side applications with which the mobile device is to interact. Assuch, in addition to configuration details for delivery mechanisms, theapplication definition file may provide an indication of deliverymechanism to use for interaction with a particular server-sideapplication.

For instance, if the server-side application is to provide the mobiledevice with instant notification of new data, a push protocol may beused as the delivery mechanism. Exemplary push protocols include UDPhole punching and the Push Access Protocol. Network Address Translatortraversal through UDP hole punching is a method for establishingbidirectional UDP connections between Internet hosts in private networksusing Network Address Translation. The Push Access Protocol is aprotocol defined in WAP-164 of the Wireless Application Protocol suitefrom the Open Mobile Alliance. In the case of UDP push, a keep alive“beacon” may be required to keep port mappings alive in public wirelessgateways.

In contrast, if the server-side application is to provide the mobiledevice with non-critical updating of data, a simple pull protocol may beused as the delivery mechanism. Exemplary pull protocols include theHypertext Transfer Protocol and the Simple Object Access Protocol. Itshould be clear to a person of ordinary skill that other client requestresponse technologies could be used. In the case of the pull protocols,the application definition file may provide an indication of a pollinginterval of a certain time duration. The mobile device using a pullprotocol for the delivery mechanism may transmit a request for an updatein a background process. Subsequent request transmissions may beseparated in time by the polling interval.

In a still further example, an application definition file may providethe mobile device with configuration details for a particular mechanismfor dealing with out of coverage scenarios on the mobile device. Forexample, the configuration details may indicate whether the deviceshould attempt to re-connect after the device has been disconnected.Additionally, the configuration details may indicate a value for anumber of times the device try to re-connect before alerting the user.Furthermore, the configuration details may indicate duration for thetime between re-connection attempts. Alternatively, the configurationdetails may indicate that the device is to notify the user whenever thedevice goes out of network coverage so that the user may be responsiblefor attempting to re-establish a connection.

Further configuration settings, such as distinctive ringing, backgroundcolor or pattern, server address for multimedia messaging, etc., mayalso be provided in an application definition file. Additionalconfiguration settings may include, for example, use of a predeterminedretry rate, use of encryption, use of an alarm to indicate that thereare more than five items in an outbound queue, use of a Secure SocketsLayer (SSL).

Advantageously, IT staff are relieved from having to configure eachdevice manually and request each application definition file manually.Upon registration, a relatively uninformed field user can quickly have aproperly configured mobile device, e.g., after accidentally erasing allmemory on the device.

Conveniently, a field user may upgrade from old mobile device hardwareto new mobile device hardware or otherwise switch mobile device hardwareand, through mechanisms representative of aspects of the presentapplication, the new mobile device hardware may be configured to haveaccess to the same server-side applications as were accessed by the oldmobile device hardware.

It will be understood that the invention is not limited to theembodiments described herein which are merely illustrative of anembodiment of carrying out the invention, and which is susceptible tomodification of form, arrangement of parts, steps, details and order ofoperation. The invention, rather, is intended to encompass all suchmodification within its scope, as defined by the claims.

1. A computer readable medium storing computer-executable instructions that, when performed by a processor of a computing device in communication with a mobile communication device, cause said computing device to facilitate configuration of said mobile communication device by: receiving a request for registration of said mobile communication device; based on said request for registration, determining an identity of a user associated with said mobile communication device; determining a set of N server-side applications associated with said identity of said user, where N is an integer greater than one; and automatically, for each of said N server-side applications: generating a document in a markup language, said document for configuring said mobile communication device to access said server-side application; and transmitting said document to said mobile communication device.
 2. The computer-readable medium of claim 1 wherein said determining said identity of said user comprises parsing said request for registration.
 3. The computer-readable medium of claim 1 wherein said determining said set of N server-side applications comprises: determining an identity of a group listing that includes said identity of said user; and identifying a plurality of application identities associated with said group listing.
 4. The computer-readable medium of claim 1 wherein said generating said document comprises combining: a format of a user interface to said server-side application at said mobile communication device; a format of network messages for exchange of data generated by said server-side application; and a format for storing data related to said server-side application at said mobile communication device.
 5. The computer-readable medium of claim 4 further comprising, before said combining: determining a type for said mobile communication device; and selecting said format of said user interface based on said type.
 6. The computer-readable medium of claim 1 wherein said generating said document comprises providing a telephone number.
 7. The computer-readable medium of claim 6 wherein said telephone number is associated with a network entity with which said mobile communication device is to form a dial-up connection to gain access to said server-side application.
 8. The computer-readable medium of claim 1 wherein said generating said document comprises providing an Internet Protocol address.
 9. The computer-readable medium of claim 8 wherein said Internet Protocol address is associated with a server with which said mobile communication device is to form a connection to gain access to said server-side application.
 10. The method of claim 8 wherein said Internet Protocol address is associated with a Virtual Private Network server with which said mobile communication device is to form a connection to gain access to said server-side application.
 11. The computer-readable medium of claim 10 wherein said generating said document further comprises providing encryption key settings.
 12. The computer-readable medium of claim 10 wherein said generating said document further comprises providing an indication of an authentication protocol.
 13. The computer-readable medium of claim 1 wherein said generating said document comprises providing an indication of a protocol for use in connecting to a server gateway which said mobile communication device is to form a connection to gain access to said server-side application, where said protocol is optimized for a predetermined type of connection to said server gateway.
 14. The computer-readable medium of claim 1 wherein said generating said document comprises providing an indication of a delivery mechanism to use for interaction with said server-side application.
 15. The computer-readable medium of claim 14 wherein said delivery mechanism is a push protocol.
 16. The computer-readable medium of claim 14 wherein said delivery mechanism is a pull protocol.
 17. The computer-readable medium of claim 1 wherein said generating said document comprises providing an indication of a mechanism for re-establishing a connection once said connection has been lost, where said connection allows access to said server-side application.
 18. A mobile communication device comprising: a processor; memory in communication with said processor storing software that, when executed by said processor, adapts said mobile communication device to: send, to a computing device, a request for registration of said mobile communication device; and receive, from said computing device, N markup language documents for configuring said mobile communication device to access N respective server-side applications via said computing device, where N is an integer greater than one, each of said N markup language documents being previously associated with an identity of a user of said mobile communication device, said N markup language documents having been automatically generated and transmitted by said computing device in response to said request for registration.
 19. The mobile communication device of claim 18 wherein said software further adapts said mobile communication device to interpret at least one of said N markup language documents for the purpose of configuring said mobile communication device to access a respective one of said N server-side applications.
 20. A computer readable medium storing computer-executable instructions that, when performed by a processor of a mobile communication device, cause said mobile communication device to: send, to a computing device, a request for registration of said mobile communication device; and receive, from said computing device, N markup language documents for configuring said mobile communication device to access N respective server-side applications via said computing device, where N is an integer greater than one, each of said N markup language documents being previously associated with an identity of a user of said mobile communication device, said N markup language documents having been automatically generated and transmitted by said computing device in response to said request for registration. 